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DETAILED ACTION 
Response to Amendment 

1 . This office action is in response to applicant's amendment and request for 
continued examination filed, 16 March 2006, of application filed, with the above serial 
number, on 16 March 2001 in which claims 1,6, 10, 15, and 19 have been amended. 
Claims 1-21 are therefore pending in the application. 

Claim Rejections - 35 USC §112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

Claims 10-14, 19-21 are rejected under 35 U.S.C. 112, second paragraph, as 
being incomplete for omitting essential steps, such omission amounting to a gap 
between the steps. See MPEP § 2172.01. The omitted steps are: It is not clear how 
the client determines the failover server in the failover group. 

Claim 15 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. The claim, as amended, is not clear. For example, the 
language "receiving a request from a client by the server", as well as the other 
limitations with "by the server" being added, (see "notifying by the server a master 
server", "processing the request by the server"; in such cases, it is not clear if the server 
is doing the processing, or if the "request by the server" is a request from the server, 
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etc). Further, it is not clear which "server" is being referred to, when antecedently there 
is a server and a plurality of servers. 

Claim 15 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. The preamble "a method for performance by a server 
configured in a failover group" is vague and difficult to comprehend. 



Claim Rejections - 35 USC § 102 

3. The following is a quotation of the appropriate paragraphs of 35 U.S.C! 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent ; 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

4. Claims 1-21 are rejected under 35 U.S.C. 102(e) as being anticipated by Le et al 
(hereinafter "Le", 6,145,089). 

Le teaches the invention as claimed including server fail-over recovery (see 
abstract). 

As per Claim 1 , Le teaches a system comprising: 

a plurality of servers organized into one or more failover groups and over which 
data is partitioned, each server usually processing client requests for data of a ; 
respective type and processing the client requests for data other than the respective 
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type for other of the plurality of servers within a same failover group when the other of 
the plurality of servers within the same failover group are offline (at least col. 3, lines 21- 
22; col. 2, lines 22-64; servers providing different services, redistributing services to 
other servers upon failure); and, 

a master server managing notifications from one or more clients and from the 
plurality of servers as to whether servers are offline, the master server verifying whether 
a server is offline when so notified, and where the server has been verified as offline, so 
notifying the plurality of servers other than the server that has been verified as offline (at 
least col. 4, lines 10-36; role manager managing heartbeat messages / server status). 

As per Claim 2. 

Le teaches the system of claim 1 , further comprising a database storing data 
responsive to client requests of any respective type and which has been partitioned 
over the plurality of servers, each server caching the data stored in the database 
responsive to client requests of the respective type (at least col. 2, lines 21-63; failover 
server redistribution of service groups). 

As per Claim 3. 

Le teaches the system of claim 2, wherein each server further temporarily caches 
the data stored in the database responsive to client requests other than the respective 
type when the other of the plurality of servers within the same failover group are offline 
(at least col. 2, lines 21-63; failover server redistribution of service groups). 

As per Claims 4 and 8. 
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Le teaches the system of claim 1 , wherein the one or more failover groups 
consists of one failover group, such that the plurality of servers are within the one 
failover group (at least col. 3 line 64 - col. 4 line 35). 

As per Claims 5 and 9. 

Le teaches the system of claim 1 , further comprising one or more clients sending 
requests to the plurality of servers (at least col. 3, lines 47-67). 
As per Claim 6, Le teaches a system comprising: 

a plurality of servers organized into one or more failover groups, each server 
usually processing client requests of a respective type and processing the client 
requests other than the respective type for other of the plurality of servers within a same 
failover group when the other of the plurality of servers within the same failover group 
are offline(at least col. 3, lines 21-22; col. 2, lines 22-64; servers providing different 
services, redistributing services to other servers upon failure); and, 

a database storing data responsive to client requests of any respective type and 
which is partitioned for caching over the plurality of servers, each server caching the 
data stored in the database responsive to client requests of the respective type, each 
server also temporarily caching the data stored in the database responsive to client 
requests other than the respective type when the other of the plurality of servers within 
the same failover group are offline (at least col. 2, lines 21-63; failover server 
redistribution of service groups). 

As per Claim 7. - 
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Le teaches the system of claim 6, further comprising a master server managing 
notifications from one or more clients and from the plurality of servers as to whether 
servers are offline, the master server verifying whether a server is offline when so 
notified, and where the server has been verified as offline, so notifying the plurality of 
servers other than the server that has been verified as offline (at least col. 4, lines 10- 
36; role manager managing heartbeat messages / server status). 

As per Claim 10, Le teaches a computer-readable medium having instructions 
stored thereon for execution by a processor to perform a method, wherein Le teaches: 

determining whether a data server of a plurality of data servers is in a failover 
mode (at least col. 4, lines 30-35); 

in response to determining that the data server is not in the failover mode, 
sending a request by a client to the data server (at least col. 4, lines 1-13; receiving 
healthy heartbeat signal); 

determining whether sending the request was successful (disruption 
determination) (at least col. 4, lines 10-36; col. 2, lines 37-63); 

in response to determining that sending the request was unsuccessful, entering 
the failover mode for the data server (at least col. 4, lines 10-50; col. 2, lines 37-63); 

notifying a master server that sending the request to one of a plurality of data 
servers was unsuccessful (role manager not receiving heartbeat message) (at least col. 
4, lines 10-36); 
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determining, by the client, a failover server, in a failover group, wherein the 
failover group is selected from a plurality of servers (elected server) (at least col. 2, lines 
37-63); and, 

sending the request to the failover server (eg. client accessing intranet through 
elected failover Server A after failure of Server C) (at least col. 2, lines 22-63; dol. 3, 
lines 21-22). 

As per Claim 11. 

Le teaches the medium of claim 10, the method initially comprising determining 
the data server as one of a plurality of data servers to which to send the request (eg. 
accessing intranet web server or customer support) (at least col. 2, lines 23-55). 

As per Claim 12. 

Le teaches the medium of claim 10, the method initially comprising in response 
to determining that sending the request was unsuccessful, repeating sending the ; 
request to the data server for a predetermined number of times, and entering the : 
failover mode for the data server if sending the request for the predetermined number of 
times was still unsuccessful (at least col. 4, lines 27-36; col. 6, lines 30-36). 

As per Claim 13. 

Le teaches the medium of claim 10, the method further comprising in response to 
determining that the data server is in the failover mode, determining whether the data 
server has been in the failover mode for longer than a predetermined length of time (at 
least col. 4, lines 27-36; col. 6, lines 30-36); and, 
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in response to determining that the data server has not been in the failover mode 
for longer than the predetermined length of time, sending the request to the failover 
server (recieivng heartbeat message within amount of time) (at least col. 4, lines 27-36; 
col. 6, lines 30-36). 

As per Claim 14. 

Le teaches the medium of claim 13, the method further comprising in response to 
determining that the data server has been in the failover mode for longer than the 
predetermined length of time, sending the request to the one of the plurality of data 
servers (sending to elected server after time-out) (at least col. 4, lines 27-36; col. 6, 
lines 30-36); 

determining whether sending the request was successful (at least col. 4, lines 27- 
36; col. 6, lines 30-36); 

in response to determining that sending the request was unsuccessful, sending 
the request to the failover server (at least col. 4, lines 27-36; col. 6, lines 30-36); 

in response to determining that sending the request was successful, exiting the 
failover mode for the data server (at least col. 4, lines 27-36; col. 6, lines 30-36); and, 

notifying the master server that sending the request to the data server was 
successful (reception of heartbeat message from each server resulting in no disruption) 
(at least col. 4, lines 1 5-51 ; col. 6, lines 30-36). 

As per Claims 15 and 18, Le teaches a method and computer-readable medium 
having instructions stored thereon for performance by a server configured in a failover 
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group, wherein the failover group is selected from a plurality of servers, wherein Le 
teaches: 

receiving a request from a client by the server (at least col. 2, lines 37-63; col. 3, 
lines 47-67; eg. accessing intranet web server or customer support); 

determining whether the request is of a type usually processed by the server (at 
least col. 2, lines 22-63; eg. intranet); 

in response to determining that the request is of the type usually processed by 
the server, processing the request by the server (at least col. 2, lines 22-63; eg. 
accessing intranet web server 123 on Server C); 

in response to determining that the request is not of the type usually processed 
by the server, determining by the server whether a second server that usually 
processes the type of the request is indicated as offline (at least col. 2, lines 22-63;;col. 
4 line 61 - col. 5 line 50) 

in response to determining that the second server that usually processes the type 
of the request is indicated as offline, processing the request by the server (at least col. 
2, lines 22-63; col. 4 line 61 - col. 5 line 50); / 

in response to determining that the second server that usually processes the type 
of the request is not indicated as offline, sending by the server the request to the 
second server (at least col. 2, lines 22-63; col. 4 line 61 - col. 5 line 50); 

in response to determining that sending the request was unsuccessful, ; 
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processing the request by the server (at least col. 2, lines 22-63; col. 4 line 61 - col. 5 
line 50; kernel acting with heartbeat manager to elect one proper server to perform the 
services requested); and, 

notifying by the server a master server that the second server is offline (at least 
col. 4, lines 10-35; role manager sending heartbeat message / electing servers) . 

As per Claim 16. 

Le teaches the method of claim 15, further comprising receiving indication from a 
master server that the second server is online (at least col. 4, lines 10-50; heartbeat 
message status). 

As per Claim 17. 

Le teaches the method of claim 15, further comprising receiving indication from a 
master server that the second server is offline (at least col. 4, lines 10-50; heartbeat 
message status). 

As per Claim 19, Le teaches a machine-readable medium having instructions 
stored thereon for execution by a processor of a master server to perform a method 
comprising: 

receiving a notification from a client that a server may be offline (at least col. 4, 
lines 10-50; eg. no heartbeat message); 

contacting the server (at least col. 4, lines 10-50); 

determining whether contacting the server was successful (at least col. 4, lines 
10-50); 
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in response to determining that contacting the server was unsuccessful, marking 
the server as offline ((at least col. 4, lines 1-51; not connecting via the first heartbeat 
network and attempting on the second heartbeat network); and, 

notifying a failover group of servers selected by the client from a plurality of 
servers, wherein the failover group is capable of processing requests for partitioned 
data of a respective type and partitioned data other than its respective type, other than 
the server marked as offline that the server is offline (at least col. 4, lines 10-50; col. 3, 
lines 21-22; col. 2, lines 22-64; servers providing different services, redistributing 
services to other servers upon failure heartbeat message status with election of 
services). 

As per Claim 20. 

Le teaches the medium of claim 19, the method further comprising periodically 
checking the server that has been marked as offline to determine whether the server is 
back online (at least col. 4, lines 1-51; col. 5, lines 29-45; receiving updates and 
heartbeat messages from servers). 

As per Claim 21 , 

Le teaches the medium of claim 20, wherein periodically checking the server that 
has been marked as offline comprising: 

contacting the server (at least col. 6 line 47 - col. 7 line 30; role manager and 
service manager staying offline until recovery and transitioning online); 
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determining whether contacting the server was successful (at least col. 6 line 47 - 
col. 7 line 30; role manager and service manager staying offline until recovery and 
transitioning online); 

in response to determining that contacting the server was successful, marking 
the server as online (at least col. 6 line 47 - col. 7 line 30; role manager and service 
manager staying offline until recovery and transitioning online); and, 

notifying the plurality of servers other than the server marked as online that the 
server is online (at least col. 6 line 47 - col. 7 line 30; role manager and service 
manager staying offline until recovery and transitioning online / using heartbeat 
messages). 

Response to Arguments 

5. Applicant's arguments filed 16 March 2006 have been fully considered but they 
are not persuasive. 

Applicants argue, substantially, that Le fails to teach a master server managing 
notifications from clients and servers as to whether a server is offline or not. However, 
Le teaches (see Fig. 3) the client(s) being connected to the service network also 
connected to the servers. Le further teaches (see Fig. 4) the service manager being 
connected to the role manager. Le further teaches the clients sending requests to the 
plurality of servers (at least col. 3, lines 47-67), such requests when not fulfilled notifying 
that the server must be offline. Thus, as the claims bring broadly interpreted do not; 
explicitly state the notifications are sent directly to the master server, and thus could be 
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derived from the clients via the servers, for example when clients communication with a 
server is not succesful, such a lack of communication resulting in a "notification" from 
the one or more clients and plurality of servers, that the server would have failed, Le 
teaches the limitations as claimed. 

Applicants further argue Le fails to teach storing data the client ultimately is 
requesting, with such data being partitioned. Examiner maintains and reiterates 
previous responses to this argument. As Applicant has previously admitted, Le teaches 
a group of servers offering different services and upon a failure of one server offering a 
service, the service being transferred to another server to provide the server to client 
requests. In this case the data is inherently partitioned (as Applicant notes in the 
background of the application, see paragraph 5), in order for the other servers to 
provide the other services, else the other servers would not be able to perform the 
service switching (and data would be out of date if not partitioned accordingly, thus-Le's 
system would not work in such a case). Thus Le teaches partitioned data so a server 
processing a certain type of client requests can process other types of client requests 
upon another server being offline. Thus, Le teaches the claimed features as Le teaches 
one server providing primarily one service and another server providing primarily 
another different service, however, when that server and thus service are no longer 
available, the other (backup) server will provide that service accordingly. 

Applicants further argue Le does not teach the client determining the faiiover 
server in a faiiover group. However, upon referring to paragraph 42 of the specification, 
it is not clear how the client can randomly determine another server with which to 
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communicate without a master server or role manager to assist the client in determining 
the faiover server. As such, a 112 rejection has been made on this issue. However, Le 
teaches the limitation, as understood in its broad form, as Le teaches the client 
obtaining the services from another server upon the failure of the first server it 
attempted to connect to, for example, when server A would fail and the client would 
attempt to connect to server A, the connection would pass to server B and thus the 
client would "determine" server B as to provide the services and communicate with at 
that time and in the future. 

Applicants further argue Le does not teach the limitations of claim 15 being ; 
performed by a server. However, a 1 12 rejection has been made on this issue as the 
claim langage is vague and difficult. However, Le teaches the limitations, as 
understood, as Le teaches a role manager performing the functions described when a 
client requests the use of a service of a server, it determines the appropriate server the 
the service requested and directs the request to the appropriate server it has 
determined can fulfill the service request from the client. In this case, "by the server" is 
being interpreted as by the role manager of Le as the role manager can reside on any 
or all servers and can fulfill the limitations of the claims as amended. 
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Conclusion 

6. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. Newly cited Podanoffsky (server groups organized according to 
respective functions) and Mashayekhi et al, in addition to previously cited Harvell, Arora 
et al, Bruck et al, Ishida (master computer management), Murphy et al (object-level 
failover specifics), Purcell et al (failover with heartbeat network), Glenn, II et al, Delaney 
et al, Hemphill et al, Rizvi et al, Abramson et al, Schoenthal et al, and Nguyen et al are 
cited for disclosing pertinent information related to the claimed invention. Applicants are 
requested to consider the prior art reference for relevant teachings when responding to 
this office action. 

7. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Gregory G. Todd whose telephone number is (571)272- 
401 1. The examiner can normally be reached on Monday - Friday 9:00am-6:00pm w/ 
first Fridays off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ario Etienne can be reached on (571)272-4001. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306: 
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Information regarding the status of an application may be obtained from. the 



Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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